Runtime virtualization and devirtualization of memory by a virtual machine monitor

ABSTRACT

A virtual machine monitor can be used to commence virtualization of computer memory at runtime. The virtual machine monitor can also be used to devirtualize computer memory at runtime.

BACKGROUND

A virtual machine monitor (“VMM”) creates an environment that allowsmultiple operating systems to run simultaneously on the same computerhardware. In such an environment, applications written for differentoperating systems (e.g., Windows, Linux) can be run simultaneously onthe same hardware.

Running an operating system on a VMM involves virtualizing one or moreof the following types of hardware: memory, I/O devices, and CPU(s).CPUs and I/O devices can be virtualized in the traditional way: thehardware is configured to trap when an operating system (“OS”) executesa privileged instruction, and the VMM simulates the completion of thatinstruction to maintain the illusion that the operating system has solecontrol of the hardware.

Memory virtualization typically involves two levels of translation,virtual-to-physical translation, which is defined by the OS, andphysical-to-machine translation, which is defined by the VMM.

Traditional operating systems employ an abstraction of memory called“virtual” memory. When the OS or application accesses a virtual address,that address is translated into a “physical” address to allow the accessto reach the real memory present in hardware. This translation istypically managed by the OS, but performed on the fly by the CPU.

The translation may be performed by dividing virtual and physical memoryup into chunks called “pages”. The OS defines the “virtual-to-physical”mapping, or V→P, that assigns a page of physical memory to hold thecontents of a particular virtual page. This mapping usually takes theform of “page tables” containing “page table entries” (PTEs). Each PTEdefines a mapping from a virtual page to a physical page (on somearchitectures, one PTE may map more than one page). The CPU maintains acache of translations in a “translation lookaside buffer” or TLB. If avirtual address is accessed for which there is not a valid translationin the TLB, the appropriate PTE is read from the currently active pagetable (pointed to by the CPU's “page table base register”), and thenloaded into the TLB. This fill operation upon a TLB miss can beperformed in hardware on some architectures, or in software on others.Often, operating systems provide each of their processes (runningapplications) with a separate virtual address space, defining a separatevirtual-to-physical mapping for each, and switching thevirtual-to-physical mapping in effect when the OS changes the processthat currently executes.

This virtual-to-physical translation alone suffices when the OS is notrunning on a VMM. However, when the OS is run on a VMM, the VMMmaintains ultimate control over the use of the memory resources, andallows multiple operating systems to share the same pool of memory. Tomaintain this control, the VMM translates the OS's physical memoryaccesses into accesses to “machine” memory. Thus the physical memory isalso employed as an abstraction, and the machine memory becomes the realmemory hardware when the OS is run on a VMM. The VMM defines the“physical-to-machine” mapping, or P→M, and maintains control over theCPU's translation activities (e.g. by setting the page table baseregister, and/or handling TLB fills). The P→M mapping assigns a page ofmachine memory to each page of physical memory. Because most CPUs onlyhave a single TLB, for performance reasons the VMM usually createsdirect mappings of virtual pages to machine pages. The direct mappingcan be created by composing dynamically the OS's V→P translations withthe VMM's P→M translations. The VMM ensures that the TLB employs thecomposed V→M translations when translating virtual accesses.

When the OS runs without a VMM underneath, the term “physical memory”refers to the real memory present in hardware. When the OS runs on a VMMthat virtualizes physical memory, the term “machine memory” refers tothe real memory present hardware. This nomenclature is standard.

Traditional VMMs impose their physical-to-machine translation on theoperating system from bootup to shutdown. Virtualizing physical memoryadds overhead to the system. For example, dynamically composing the V→Ptranslations with the P→M translations slows the OS's normal memorymanagement. Overhead is also added by constantly trapping and simulatingprivileged instructions. This overhead can slow interrupt handling,increase the fraction of CPU bandwidth lost to software overhead,increase response time, and decrease perceived performance.

Since the VMM virtualizes the hardware from bootup to shutdown, overheadis incurred even while virtualization is not necessary (for example,when only a single OS instance is running on the hardware). Thus the VMMcan add unnecessary overhead to the computer.

It would be desirable to reduce the unnecessary overhead of the VMM.

SUMMARY

A virtual machine monitor is running on computer hardware. The hardwareincludes machine memory. According to one aspect of the presentinvention, virtualization of the memory is commenced at runtime.According to another aspect of the present invention, the memory isdevirtualized at runtime.

Other aspects and advantages of the present invention will becomeapparent from the following detailed description, taken in conjunctionwith the accompanying drawings, illustrating by way of example theprinciples of the present invention.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 is an illustration of hardware and software layers of a computerin accordance with an embodiment of the present invention.

FIG. 2 is an illustration of a method of using a VMM in accordance withthe present invention.

FIG. 3 is an illustration of a method of devirtualizing physical memoryin accordance with an embodiment of the present invention.

FIGS. 4 a and 4 b are illustrations of memory before and afterremapping.

FIG. 5 is an illustration of a method of remapping physical memory inaccordance with an embodiment of the present invention.

FIG. 6 is an illustration of a particular step in the remapping methodof FIG. 5.

FIGS. 7 a-7 b are illustrations of another step in the remapping methodof FIG. 5.

FIG. 8 is an illustration of a method of virtualizing memory at runtime.

DETAILED DESCRIPTION

As shown in the drawings for purposes of illustration, the presentinvention is embodied in a computer that runs a virtual machine monitor.The computer is not limited to any particular type. The computer can be,for example, a file server, web server, workstation, mainframe, personalcomputer, personal digital assistant (PDA), print server, or networkappliance. The computer can be contained in a single box, or distributedamong several boxes.

FIG. 1 shows different layers of an exemplary computer 100. The computer100 has a raw hardware layer 110 and a software layer 111. The rawhardware layer 110 typically includes a central processing unit (CPU),memory and I/O devices. Exemplary I/O devices include, withoutlimitation, network adapters, SCSI controllers, video cards, host busadapters, and serial port adapters. The memory refers to the memory thatis internal to the computer (e.g., internal memory cache, main systemmemory) as opposed to external storage devices such as disk drives.

The software layer 111 includes one or more OS instances 112, a VMM 114,and applications 116. The VMM 114 runs between the raw hardware layer110 and the OS instances 112. The VMM 114 allows one or more OSinstances 112 to run simultaneously. The applications 116 are run on theOS instance(s) 112. During execution, the software for the softwarelayer 111 can be stored in “articles” such as the memory; and duringdistribution, the software can be stored in articles such as externaldevices, removable storage media (e.g., optical discs), etc.

The VMM 114 can commence virtualization of the physical memory atruntime. Such virtualization at runtime is referred to as “runtimevirtualization of memory.” The VMM 114 can also cease the virtualizationof physical memory at runtime. Such cessation is referred to as “runtimedevirtualization of memory.” Runtime is the period of normal executionof the operating system after boot and before shutdown.

Reference is made to FIG. 2, which illustrates an exemplary method ofperforming runtime virtualization and devirtualization of memory. TheVMM is booted on the hardware layer 110, and receives control of thehardware layer 110 at boot time (210). Thus the memory is virtualized.

Multiple OS instances can be run on the virtual machine (212). Tosupport the runtime virtualization and devirtualization of memory, theVMM exposes to each OS instance physical memory no larger than machinememory. No extent of physical memory spans a “hole” in machine memory.In other words, for each page of physical memory exposed to the OSinstance as it boots, there exists a page of machine memory with thesame page frame number (i.e. address). If the VMM can map multiple pagesof physical memory to the same page of machine memory, those physicalpages are logically independent (e.g. marked read-only or“copy-on-write”). If the VMM exposes to the OS instance a physical pagecontaining memory-mapped I/O devices, the VMM exposes that page at thesame physical address as that page occurs in machine memory.

The VMM creates data structures that support runtime virtualization anddevirtualization (214). The VMM may maintain a “back map” that containsfor each page of machine memory a list of the pages of physical memorythat map to it. The VMM runs in a range of machine memory such that thephysical memory pages with the same page frame numbers are not exposedto the OS instance. Finally, the VMM maintains a list of free machinepages. Devirtualization can increase the amount of memory used by thesystem, and the VMM has enough free pages to support this increase. Thefree list may be sorted to allow the VMM to test efficiently whether aparticular page of machine memory is free.

As an OS instance runs on the VMM, the VMM virtualizes memory bymanaging the P→M mapping. The VMM can take one page of machine memoryaway from the OS instance by picking a page p of physical memory(according to its page replacement policy, such as the “least recentlyused” page), writing the contents of that page to stable storage,updating the P→M mapping so that the physical page p no longer maps toany page of machine memory, and flushing any PTEs involving physicalpage p from the TLB. If later the OS instance accesses physical page p,that access will trap to the VMM (since the PTEs were flushed). The VMMcan allocate a page of machine memory m from its list of free machinepages, read into that page from stable storage the prior contents ofphysical page p, then update the P M mapping to map physical page p tomachine page m, and restart the instruction that caused the trap. Notethat x and m may not be the same machine page, and that physical page pcan map to almost any page of machine memory. The VMM can map severaldifferent pages of physical memory to the same machine page (if all thephysical pages contain read-only data, for example). Thus the VMM canchange the P→M mapping frequently, and physical pages may map todifferent machine pages over time.

Once the memory virtualization is not needed (for example,virtualization may no longer be needed when only a single OS runs), thememory may be devirtualized (216). Devirtualizing the memory reduces anyunnecessary overhead associated with the virtualization of it. When itbecomes necessary to virtualize the memory, the runtime virtualizationis performed (218). When virtualization of the memory is no longerneeded, the memory is devirtualized again (220).

Reference is now made to FIG. 3, which illustrates a method ofdevirtualizing physical memory. Physical memory is remapped so that theP→M mapping is the Identity mapping (310). An Identity mapping is anotion from mathematics in which each element in the mapping maps toitself. For example, in an Identity P→M mapping, for each mapped page ofphysical memory, if that page is at physical address x, then it ismapped to the page of machine memory at machine address x. The goal ofthis step is to move pages of machine memory around and rewrite the P→Mmapping so that, when finished, each page of physical memory maps to thepage of machine memory with the same page frame number. The Identitymapping may be constructed at runtime or before runtime.

FIG. 4 a illustrates virtual memory, physical memory and machine memorybefore remapping. The OS defines the V→P mapping and the P→M mapping.Each page of physical memory can map to a page of machine memory havinga different page frame number.

FIG. 4 b illustrates the virtual memory, the physical memory and themachine memory after remapping. Each page of physical memory maps to apage of machine memory having the same page frame number.

Returning to FIG. 3, the computer is configured to translate virtualmemory accesses using directly the V→P mapping defined by the operatingsystem (312). Different platforms and architectures may have differentrequirements for configuring the computer. On some platforms, directlyusing the OS's V→P mapping involves setting the CPU's “page table baseregister” to point to the OS's page table(s). On other platforms, theVMM's TLB miss routine loads the OS's PTEs into the TLB, without furthercomposing them with the VMM's own P→M mapping. On other platforms, thehardware may be reconfigured to invoke a TLB fill routine in the OSinstead of in the VMM.

Reference is next made to FIG. 5, which illustrates an exemplary methodof remapping physical memory so the P→M mapping becomes the Identitymapping. This method can be carried out by the VMM. In this exemplarymethod, all memory accesses by the operating system and applications arepaused during remapping.

The VMM examines each page of physical memory that is mapped in the P→Mmapping (510). If a physical page p is mapped to machine page p in theP→M mapping, and no other physical pages are mapped to machine page p(512), then the physical page p is already mapped via the Identitymapping and remapping can continue with the next physical page (510). Ifphysical page p is not already Identity-mapped (512), the VMM searchesits list of free machine pages to see whether machine page p is free(514). If the machine page p is free, the physical page p is directlyremapped to machine page p (516). Otherwise, the physical page p isremapped in an indirect manner, after first remapping those physicalpages that map to machine page p (518). Once physical page p has beenremapped to machine page p, existing translations involving physicalpage p are flushed from the TLB (520). The translations for page p maybe flushed by having the VMM flush the entire TLB. However, somearchitectures allow the VMM to flush only those translations thatinvolve physical page p. Since the TLB typically caches V→M translations(V→P translations composed with P→M translations), and the OS may chooseto map more than one virtual page to the same physical page, the VMM mayhave to flush more than one PTE in the TLB involving physical page p.The remapping is finished when each physical page in the P→M mapping ismapped to a page in machine memory having the same page frame number(522).

Reference is now made to FIG. 6, which illustrates how the VMM candirectly remap physical page p to machine page p. The VMM removesmachine page p from its list of free machine pages (610). Next, the VMMcopies machine page x to machine page p, where x is the machine page towhich p is mapped in the P→M mapping (612). The VMM then removesphysical page p from the list of pages in the back map for machine pagex (614), and if that list becomes empty, adds machine page x to the listof free machine pages (616). The VMM then adds physical page p to theback map for machine page p (618), and updates the P→M mapping to mapphysical page p to machine page p (620).

Reference is now made to FIGS. 7 a-7 b, which illustrate how the VMM canremap physical page p indirectly by first remapping those pages thatalready map to machine page p. The VMM first allocates a free page tfrom its list of free machine pages (710), and copies machine page p tomachine page t (712). Next, the VMM examines each physical page i in thelist of pages in the back map for machine page p (714). The VMM removesphysical page i from machine page p's back map (716), adds physical pagei to the back map for machine page t (718), and updates the P→M mappingso physical page i maps to machine page t (720). The VMM ensures thatthe updated mapping for physical page i takes effect (722). Forinstance, the VMM can flush the entire TLB, or flush just those cachedtranslations that involve physical page i.

Once all the pages in machine page p's back map have been remapped(524), the VMM can then remap physical page p in much the same manner asin the direct remapping. The VMM copies machine page x to machine pagep, where x is the machine page to which p is mapped in the P→M mapping(726). The VMM then removes physical page p from the list of pages inthe back map for machine page x (728), and if that list becomes empty,adds machine page x to the list of free machine pages (730). The VMMthen adds physical page p to the back map for machine page p (732), andupdates the P→M mapping to map physical page p to machine page p (734).

The devirtualization described above takes place while OS andapplication processing are paused. However, the method is not solimited. The VMM can be designed to perform devirtualizationconcurrently with OS and application processing. While remappingphysical page p, the VMM should ensure that other VMM threads do notmodify entries involving p in the P→M mapping and the back map (forexample, the VMM may acquire and hold a lock for page p while p isremapped). Once page p has been remapped for the Identity mapping, theVMM should ensure either the mapping for p is not modified beforeallowing an OS instance to directly manage memory translation (312), orthat page p is again considered a candidate for remapping (510).Finally, the VMM temporarily prevents write access by the OS instance orapplication to virtual or physical pages while their backing machinepages are copied and the mappings to those machine pages are updated.This write access should be prevented during the windows of time betweenthe initiation of step 612 and the completion of step 520, between theinitiation of step 712 and the completion of step 724, and between theinitiation of step 726 and the completion of step 520.

Reference is now made to FIG. 8, which illustrates a method ofvirtualizing memory at runtime, where the VMM already has control of theCPU. For example, the VMM runs in a more privileged mode to get controlon key hardware traps. In the alternative, the VMM previouslydevirtualized memory, but not the CPU. OS and application processing maybe paused while the memory is virtualized.

To perform runtime virtualization of memory, the VMM constructs aninitial P→M mapping that is the Identity mapping (810). At thecompletion of this step, each physical page known to the OS instance ismapped in P→M to the machine page with the same page frame number. TheVMM may also initialize its back map such that for each page of machinememory mapped in P→M, the back map of that page contains only the pageof physical memory with the same page frame number.

The VMM also configures the hardware to translate virtual memoryaccesses using the VMM's P→M mapping in addition to the OS instance'sV→P mapping (812). Configuring the hardware may involve setting theCPU's page table base register to point to page tables maintained by theVMM. The configuration may also involve having the VMM's TLB missroutine commence composing the VMM's P→M translations with the OSinstance's V→P translations. The hardware may also be configured toinvoke a TLB fill routine in the VMM rather than in an OS instance. Atthe completion of these steps (810 and 812), physical memory isvirtualized. OS and Application processing can resume.

Although the P→M mapping is initially the Identity mapping, oncephysical memory is virtualized, the VMM is free to change over time howphysical memory maps to machine memory.

The VMM can be designed to support the runtime virtualization anddevirtualization of only a portion of physical memory. Whendevirtualizing a portion of physical memory, the VMM may remap in themanner depicted in FIG. 5 only those physical pages to be devirtualized.Once those pages are mapped in P→M via the Identity mapping, the VMM cancease composing V→P translations with the VMM's P→M translations for therange of physical memory that has been devirtualized, and can allow thehardware to directly employ the OS instance's V→P translations in thatrange.

The VMM can support runtime virtualization of a portion of physicalmemory by constructing an initial Identity P M mapping for that range ofphysical memory, and commencing the composition of the OS instance's V→Ptranslations with the VMM's P→M translations in that range of physicalmemory.

In the methods described above, the VMM maintains a back map detailingwhich physical pages map to each page of machine memory. However, theVMM is not so limited. Instead of maintaining a machine memory back mapand querying the back map to determine whether a machine page should beadded to the free list, the VMM may instead maintain a reference countfor machine page x, and free it when the reference count of machine pagex reaches zero. The VMM may also search the P→M mapping to see whetherany physical pages still map to machine page x and free those physicalpages if the VMM finds none. Similarly, the VMM may construct the listof pages in step 714 by searching through the P→M mapping for thosephysical pages mapped to machine page p.

The remapping of physical memory during devirtualization is notperformed for physical pages containing I/O addresses if the VMM alreadymaps those physical pages to machine pages at the same address (that is,if I/O space is already Identity-mapped).

Thus disclosed is a VMM that can reduce unnecessary overhead. Anoperating system need not be modified to run on the VMM or designed forthat purpose, but instead may be a commodity operating system withoutspecial support for running in a virtual machine (such as MicrosoftWindows, Linux, Tru64 Unix, etc.). Similarly, the raw hardware layerneed not provide special support for the VMM. The VMM can work oncommodity hardware not having features that help or acceleratevirtualization (such as Intel x86, Intel Itanium, and HP Alphaprocessors).

The present invention is not limited to the specific embodimentsdescribed and illustrated above. Instead, the present invention isconstrued according to the claims that follow.

1. A method of running a virtual machine monitor on computer hardware,the hardware including memory, the method comprising commencingvirtualization of the memory at runtime.
 2. The method of claim 1,wherein the virtualization includes constructing an Identity mapping ofphysical to machine memory; and commencing to use the virtual machinemonitor at runtime to manage memory translation.
 3. The method of claim2, wherein the Identity mapping is constructed prior to runtime.
 4. Themethod of claim 2, wherein the memory translation is initially performedaccording to the Identity mapping.
 5. The method of claim 4, wherein thevirtual machine monitor modifies the mapping after the physical memoryhas been virtualized.
 6. The method of claim 2, wherein an operatingsystem is running on the virtual machine monitor prior to virtualizingthe memory; and wherein the memory translation is managed by allowingthe operating system to define virtual-to-physical mapping, and thevirtual machine monitor to define physical-to machine mapping.
 7. Themethod of claim 6, wherein the virtual machine monitor dynamicallycomposes virtual-to-physical translations with physical-to-machinetranslations.
 8. The method of claim 6, wherein the virtual machinemonitor inspects the virtual-to-physical mappings by the operatingsystem and maintains page tables of virtual-to-machine mappings.
 9. Themethod of claim 6, further comprising loading a translation lookasidebuffer with virtual-to-machine translations.
 10. The method of claim 1,wherein only a portion of physical memory is virtualized at runtime. 11.The method of claim 1, wherein the hardware includes a CPU that wasvirtualized prior to the virtualization of the memory.
 12. The method ofclaim 1, further comprising performing runtime devirtualization of thevirtualized memory.
 13. A method of running a virtual machine monitor oncomputer hardware and an operating system on the virtual machinemonitor, the hardware including memory, the memory virtualized by thevirtual machine monitor, the method comprising devirtualizing the memoryat runtime.
 14. The method of claim 13, wherein a portion of the memoryis devirtualized.
 15. The method of claim 13, wherein when the operatingsystem is booted, the virtual machine monitor exposes the bootingoperating system to physical memory no larger than machine memory, wherethe physical memory does not span any memory holes.
 16. The method ofclaim 13, wherein the operating system defines virtual-to-physicaltranslations prior to the runtime devirtualization; wherein the virtualmachine monitor defines physical-to-machine translations prior to theruntime devirtualization; wherein the virtual machine monitor composesdynamically the virtual-to-physical translations with thephysical-to-machine translations prior to the runtime devirtualization,wherein the runtime devirtualization includes having the virtual machinemonitor cease to perform the dynamic composition of translations; andwherein following the runtime devirtualization memory translation isperformed by directly using the virtual-to-physical mapping defined bythe operating system.
 17. The method of claim 13, wherein thedevirtualization includes remapping physical memory so aphysical-to-machine mapping becomes an Identity mapping; and using theoperating system to manage address translation with respect to thedevirtualized memory.
 18. The method of claim 17, wherein pages ofphysical memory that are already Identity-mapped are not remapped, andwherein at least some other pages of physical memory are remappeddirectly.
 19. The method of claim 17, wherein pages of physical memorythat are already Identity-mapped are not remapped, and wherein at leastsome other pages of physical memory are remapped indirectly.
 20. Themethod of claim 17, wherein the remapping of the physical memory isperformed concurrently with operating system and application activity.21. The method of claim 20, further comprising preventing thephysical-to-machine mapping from being modified during the remapping,and temporarily preventing some or all write accesses to memory.
 22. Themethod of claim 17, wherein the operating system and any applicationactivity is paused while the remapping is performed.
 23. The method ofclaim 17, further comprising maintaining a back map that contains foreach page of machine memory a list of the pages of physical memory thatmap to it, and a list of free machine pages.
 24. The method of claim 17,wherein the remapping is performed without a back map by maintaining areference count for each machine page is kept, and freeing machine pageswhen their reference counts are zero.
 25. The method of claim 17,wherein the remapping is performed without a back map by constructing alist of the physical pages mapping to a page of machine memory bysearching the physical-to-machine mapping.
 26. The method of claim 17,wherein managing the address translation includes having the virtualmachine monitor cease to inspect the operating system'svirtual-to-physical translations; and ceasing to maintain a page tableof direct virtual-to-machine mappings.
 27. The method of claim 17,wherein managing the address translation includes having the virtualmachine monitor cease to compose dynamically the operating system'svirtual-to-physical translations with the virtual machine monitor'sphysical-to-machine translations for a portion of physical memory thatis devirtualized.
 28. A computer comprising memory including first andsecond portions, the first portion encoded with a virtual machine forcommencing virtualization of the second portion at runtime.
 29. Thecomputer of claim 28, wherein the virtualization includes constructingan Identity mapping of physical to machine memory; and commencing to usethe virtual machine monitor at runtime to manage memory translation. 30.The computer of claim 29, wherein the virtual machine monitor modifiesthe mapping after the physical memory has been virtualized.
 31. Thecomputer of claim 29, wherein an operating system is running on thevirtual machine monitor prior to virtualizing the memory; and whereinthe memory translation is managed by allowing the operating system tomanage virtual-to-physical mapping, and allowing the virtual machinemonitor to manage physical-to machine mapping.
 32. The computer of claim31, wherein the virtual machine monitor dynamically composesvirtual-to-physical translations with the physical-to-machinetranslations.
 33. The computer of claim 31, wherein the virtual machinemonitor inspects the virtual-to-physical mappings by the operatingsystem and maintains page tables of virtual-to-machine mappings.
 34. Thecomputer of claim 31, wherein a translation lookaside buffer is loadedwith the virtual-to-machine translations.
 35. The computer of claim 28,wherein only a portion of physical memory is virtualized at runtime. 36.An article for a computer, the article comprising computer memoryincluding a first portion encoded with a virtual machine monitor forcommencing the virtualization of a second portion of the memory atruntime.
 37. The article of claim 36, wherein the virtualizationincludes constructing an Identity mapping of physical to machine memory;and commencing to use the virtual machine monitor at runtime to managememory translation.
 38. The article of claim 37, wherein the virtualmachine monitor can modify the mapping after the physical memory hasbeen virtualized.
 39. The article of claim 37, wherein the memorytranslation is managed by allowing an operating system to managevirtual-to-physical mapping, and allowing the virtual machine monitor tomanage physical-to machine mapping.
 40. The article of claim 39, whereinthe virtual machine monitor can dynamically compose virtual-to-physicaltranslations with the physical-to-machine translations.
 41. The articleof claim 39, wherein the virtual machine monitor can inspect thevirtual-to-physical mappings by the operating system and maintains pagetables of virtual-to-machine mappings.
 42. The article of claim 37,wherein the virtual machine monitor can load a translation lookasidebuffer with virtual-to-machine translations.
 43. The article of claim36, wherein the virtual machine monitor can virtualize only a portion ofphysical memory at runtime.
 44. A computer comprising hardware includingmemory; and a virtual machine monitor for virtualizing the memory anddevirtualizing the memory at runtime.
 45. The computer of claim 44,wherein a portion of the memory is devirtualized.
 46. The computer ofclaim 44, wherein when an operating system is booted, the virtualmachine monitor exposes the booting operating system to physical memoryno larger than machine memory, where the physical memory does not spanany memory holes.
 47. The computer of claim 44, wherein an operatingsystem defines virtual-to-physical translations prior to the runtimedevirtualization; wherein the virtual machine monitor definesphysical-to-machine translations prior to the runtime devirtualization;wherein the virtual machine monitor composes dynamically thevirtual-to-physical translations with the physical-to-machinetranslations prior to the runtime devirtualization; wherein the runtimedevirtualization includes having the virtual machine monitor cease toperform the dynamic composition of translations; and wherein after theruntime devirtualization is performed, memory translation is performedby directly using the virtual-to-physical mapping defined by theoperating system.
 48. The computer of claim 44, wherein thedevirtualization includes remapping physical memory so aphysical-to-machine mapping becomes an Identity mapping; and using anoperating system to manage address translation with respect to thedevirtualized memory.
 49. The computer of claim 48, wherein pages ofphysical memory that are already Identity-mapped are not remapped, andwherein at least some other pages of physical memory are remappeddirectly.
 50. The computer of claim 48, wherein pages of physical memorythat are already Identity-mapped are not remapped, and wherein at leastsome other pages of physical memory are remapped indirectly.
 51. Thecomputer of claim 48, wherein the remapping of the physical memory isperformed concurrently with operating system and application activity.52. The computer of claim 51, wherein the physical-to-machine mapping isprevented from being modified during the remapping, and some or allwrite accesses to memory are temporarily prevented.
 53. The computer ofclaim 48, wherein the operating system and any application activity ispaused while the remapping is performed.
 54. The computer of claim 48,wherein managing the address translation includes having the virtualmachine monitor cease to inspect the operating system'svirtual-to-physical translations; and wherein maintenance of a pagetable of direct virtual-to-machine mappings is ceased.
 55. The computerof claim 48, wherein managing the address translation includes havingthe virtual machine monitor cease to compose dynamically the operatingsystem's virtual-to-physical translations with the virtual machinemonitor's physical-to-machine translations for a portion of physicalmemory that is devirtualized.
 56. An article for a computer includinghardware, the hardware including computer memory, the article comprisingmemory encoded with software for devirtualizing the computer memory atruntime.
 57. The article of claim 56, wherein the software causes aportion of the memory to be devirtualized.
 58. The article of claim 56,wherein the software includes a virtual machine monitor; and whereinwhen an operating system is booted on the virtual machine monitor, thevirtual machine monitor exposes the booting operating system to physicalmemory no larger than machine memory, where the physical memory does notspan any memory holes.
 59. The article of claim 56, wherein an operatingsystem defines virtual-to-physical translations prior to the runtimedevirtualization; wherein the software includes a virtual machinemonitor for defining physical-to-machine translations prior to theruntime devirtualization, composing dynamically the virtual-to-physicaltranslations with the physical-to-machine translations prior to theruntime devirtualization, and ceasing to perform the dynamic compositionof translations during the runtime virtualization; and wherein after theruntime devirtualization is performed, memory translation is performedby directly using the virtual-to-physical mapping defined by theoperating system.
 60. The article of claim 56, wherein thedevirtualization includes remapping physical memory so aphysical-to-machine mapping becomes an Identity mapping; and using anoperating system to manage address translation with respect to thedevirtualized memory.
 61. The article of claim 60, wherein pages ofphysical memory that are already Identity-mapped are not remapped, andwherein at least some other pages of physical memory are remappeddirectly.
 62. The article of claim 60, wherein pages of physical memorythat are already Identity-mapped are not remapped, and wherein at leastsome other pages of physical memory are remapped indirectly.
 63. Thearticle of claim 60, wherein the remapping of the physical memory isperformed concurrently with operating system and application activity.64. The article of claim 63, wherein the physical-to-machine mapping isprevented from being modified during the remapping, and some or allwrite accesses to memory are temporarily prevented.
 65. The article ofclaim 60, wherein the operating system and any application activity ispaused while the remapping is performed.
 66. The article of claim 60,wherein the software includes a virtual machine monitor that manages theaddress translation by ceasing to inspect the operating system'svirtual-to-physical translations; and wherein maintenance of a pagetable of direct virtual-to-machine mappings is ceased.
 67. The articleof claim 60, wherein the software includes a virtual machine monitor formanaging the address translation by ceasing to compose dynamically theoperating system's virtual-to-physical translations with the virtualmachine monitor's physical-to-machine translations for a portion ofphysical memory that is devirtualized.